Continuity in Software Systems

Most engineering artifacts behave in a continuous fashion, and this property is generally believed to underlie their dependability. In contrast, software systems do not have continuous behavior, which is taken to be an underlying cause of their undependability. The theory of software reliability has been questioned because technically the sampling on which it is based applies only to continuous functions. This paper examines the role of continuity in engineering, particularly in testing and certifying artifacts, then considers the analogous software situations and the ways in which software is intrinsically unlike other engineered objects. Several definitions of software ‘continuity’ are proposed and related to ideas in software testing. It is shown how ‘continuity’ can be established in practice, and the consequences for testing and analysis of knowing that a program is ‘continuous.’ Underlying any use of software ‘continuity’ is the continuity of its specification in the usual mathematical sense. However, many software applications are intrinsically discontinuous and one reason why software is so valuable is its natural ability to handle these applications, where it makes no sense to seek software ‘continuity’ or to blame poor dependability on its absence. 1. INTUITIVE CONTINUITY The untrustworthy nature of software systems running on digital computers is often blamed on the lack of continuity inherent in these systems. The absence of continuity is an ‘obvious’ fact that is seldom precisely stated or considered. The intuitive meaning of continuity, as it relates to the behavior of systems, can be seen from a description of the role continuity plays in a simple mechanical tool. 1.1 The Shovel as a Continuous System The usual garden shovel is constructed by inserting a wooden handle into a tubular socket in a metal blade. The resulting tool is very versatile, and can be used to dig out a rock or a tree stump. In this application, the blade of the shovel is forced under the rock, and Supported by NSF ITR grant CCR-0112654 the handle used to pry. The shovel acts as a lever with the fulcrum at the top of the blade where it joins the handle (bearing against the ground at the side of the hole), the blade being one arm of the lever and the handle the other. Because the handle is longer, a large upward force can be brought to bear on the rock as the handle is pushed down. Anyone who has used a shovel in this way knows that it is possible to break the tool on a too-large rock. The handle breaks just where it goes into the blade socket, or the blade itself fractures at the base of the socket. The experienced rock digger learns to sense the limits of a shovel, which is possible because the behavior of the shovel is continuous. Intuitively, as more force is applied to the handle, the stress at the weakest point of the tool rises, and does so in a simple way: a bit more force, a bit more stress. The relationship is not necessarily linear (although often it is, in so called elastic behavior), but the stress changes smoothly with the force – in a word, the change is continuous. The shovel breaks when the stress exceeds what the materials can bear. The experienced shovel user learns to stay in the continuous region, and can thus depend on a shovel year after year. Suppose that the behavior of a shovel were not continuous as described in the previous paragraph, the stress not smoothly related to the applied force. Then a digger might find that at a certain peculiar applied force value the handle suddenly snaps, even though in previous digging it was fine for forces both smaller and larger than this. Such a shovel would be hopeless to use, because one would never know when it was going to misbehave. 1.2 The Software Analogy The analogy between software systems and shovels is obvious: if the software is analogous to the shovel, the data inputs to the system are like the applied force, and the system outputs are like the stress. The system breaks (fails) when an output is incorrect. The software system is not intuitively continuous, because no matter how much it has been used (tested) without failure, it can happen that an input causes it to fail, and that input can be arbitrarily close to other inputs that did not fail. To carry things a bit farther, it is possible to test a shovel by prying with a few different forces, and if it does not break on these tests, to know that it will not break at intermediate values. This is precisely what cannot be done for software. There is also a deeper sense in which continuity applies to shovels but not to software. The parameters that define an individual shovel in a batch produced by some manufacturing process also enter into the behavior of the shovel in a continuous way. This means that it is possible to take a sample from the shovel production line, test these few shovels, and then statistically predict how the entire population of shovels is likely to behave. (For example, to assign a probability and confidence to the proposition that no shovel will break for any applied force in a given range of values.) This statistical sampling is called ‘life testing,’ and it is the original source for the theory of software reliability [13], in which the sampling is analogous to a random software test. The use of life-testing theory is technically invalid for software, because the samples are not drawn from a continuous distribution. 2. FORMAL DEFINITIONS OF SOFTWARE ‘CONTINUITY’ The definition of a continuous real function is the most intuitively appealing, and describes the behavior of many physical systems like the shovel. DEFINITION: A real function f is continuous at x0 iff: Given any > 0; 9Æ > 0 such that 8x (jx x0j < Æ =) jf(x) f(x0)j < ): (1)